[Amazon FSx for NetApp ONTAP] ファイルシステムやSVMからpingとtracerouteを実行してみた
疎通できない場合の切り分けを行いたい
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)を使用していて、不通時のネットワーク的な切り分けを行いたいなと思ったことはありますか? 私はあります。
不通時は切り分けのために、クライアントとサーバーの双方向からpingやtracerouteを打ち合うことがあります。
ONTAPでもnetwork pingとnetwork tracerouteがあることが紹介されています。
実際に使ってみました。
いきなりまとめ
- ノードを指定してpingを実行しても疎通できない
- LIFを指定した場合は疎通できる
- tracerouteはノード、LIF指定どちらでも疎通できる
- tcpdumpの実行が可能
- 出力先はFSxNのボリューム内
- pcapフィルターによる絞り込みも可能
やってみた
検証環境
検証環境は以下のとおりです。
FSxNからAD DCに対してpingやtracerouteを叩きます。
ping
ノードを指定する場合
まず、pingからです。
事前の確認として、ONTAPバージョンとnetwork
のサブコマンドを確認しておきます。
::> version
NetApp Release 9.14.1P9: Mon Oct 21 18:04:05 UTC 2024
::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
::*> network ?
cloud> *Manage cloud-based features
connections> The connections directory
fcp> The fcp directory
interface> Manage logical interfaces
ipspace> Manage IP Spaces
ndp> *Manage Neighbor Discovery Protocol
ping Ping
ping6 Ping an IPv6 address
port> Manage network ports
route> Manage routing tables
subnet> The subnet directory
test-path *Test path performance between two nodes
traceroute Traceroute
traceroute6 traceroute6
network ping
のオプションを確認しておきます。
::*> network ping ?
{ -node <nodename> Node
| -lif <lif-name> } Logical Interface
-vserver <vserver> Vserver
[ -use-source-port {true|false} ] *(DEPRECATED)-Use Source Port of Logical Interface
[-destination] <Remote InetAddress> Destination
[ -show-detail|-s [true] ] Show Detail Output
[ -record-route|-R [true] ] Record Route
[ -verbose|-v [true] ] Show All ICMP Packets
[ -packet-size <integer> ] Packet Size
[ -count <integer> ] Count
[ -wait <integer> ] Packet Send Wait Time (secs)
[ -flood [true] ] *Flood Ping
[ -disallow-fragmentation|-D [true] ] Disallow Packet Fragmentation (default: false)
[ -wait-response <integer> ] Packet Response Wait Time (ms) (default: 10000)
[ -services <LIF Service Name>, ... ] Services
ノードもしくはLIFを指定する必要があるようです。
::*> network ping -destination 10.0.0.139 -node FsxId0e64a4f5386f74c87-01
no answer from 10.0.0.139
::*> network ping -destination 10.0.0.139 -node FsxId0e64a4f5386f74c87-02
no answer from 10.0.0.139
おや、疎通できないようです。
詳細情報を出力するようにオプションを指定して再度実行します。
::*> network ping -destination 10.0.0.139 -node FsxId0e64a4f5386f74c87-01 -R true -s true
PING 10.0.0.139 (10.0.0.139): 56 data bytes
--- 10.0.0.139 ping statistics ---
20 packets transmitted, 0 packets received, 100.0% packet loss
特に手がかりはありませんね。
LIFを指定する場合
ノードを指定した場合は疎通できませんでしたが、LIFを指定する場合はどうでしょう。
各LIFのIPアドレスを確認します。
7::*> network interface show
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
FsxId0e64a4f5386f74c87
fsxadmin up/up 10.0.8.166/24 FsxId0e64a4f5386f74c87-01
e0e true
inter_1 up/up 10.0.8.229/24 FsxId0e64a4f5386f74c87-01
e0e true
inter_2 up/up 10.0.8.62/24 FsxId0e64a4f5386f74c87-02
e0e true
svm
iscsi_1 up/up 10.0.8.90/24 FsxId0e64a4f5386f74c87-01
e0e true
iscsi_2 up/up 10.0.8.210/24 FsxId0e64a4f5386f74c87-02
e0e true
nfs_smb_management_1
up/up 10.0.8.246/24 FsxId0e64a4f5386f74c87-01
e0e true
svm2
iscsi_1 up/up 10.0.8.14/24 FsxId0e64a4f5386f74c87-01
e0e true
iscsi_2 up/up 10.0.8.172/24 FsxId0e64a4f5386f74c87-02
e0e true
nfs_smb_management_1
up/up 10.0.8.189/24 FsxId0e64a4f5386f74c87-01
e0e true
9 entries were displayed.
いくつかのLIFからpingを叩きます。
::*> network ping -destination 10.0.0.139 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87
10.0.0.139 is alive
::*> network ping -destination 10.0.0.139 -lif nfs_smb_management_1 -vserver svm
10.0.0.139 is alive
::*> network ping -destination 10.0.0.139 -lif nfs_smb_management_1 -vserver svm2
10.0.0.139 is alive
疎通できましたね。
実際に指定したLIFのIPアドレスからpingが叩かれているか確認するために、オプションを付与します。
::*> network ping -destination 10.0.0.139 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87 -s true -R true
PING 10.0.0.139 (10.0.0.139) from 10.0.8.166: 56 data bytes
64 bytes from 10.0.0.139: icmp_seq=0 ttl=128 time=0.398 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=1 ttl=128 time=0.403 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=2 ttl=128 time=0.434 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=3 ttl=128 time=0.377 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=4 ttl=128 time=0.398 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=5 ttl=128 time=0.405 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=6 ttl=128 time=0.406 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=7 ttl=128 time=2.348 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=8 ttl=128 time=0.383 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=9 ttl=128 time=0.394 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=10 ttl=128 time=0.398 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=11 ttl=128 time=0.516 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=12 ttl=128 time=0.384 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=13 ttl=128 time=0.386 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=14 ttl=128 time=0.401 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=15 ttl=128 time=0.403 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=16 ttl=128 time=0.420 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=17 ttl=128 time=0.401 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=18 ttl=128 time=0.489 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=19 ttl=128 time=0.408 ms
wrong total length 84 instead of 124
--- 10.0.0.139 ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.377/0.508/2.348/0.424 ms
::*> network ping -destination 10.0.0.139 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87 -s true -R true -count 4
PING 10.0.0.139 (10.0.0.139) from 10.0.8.166: 56 data bytes
64 bytes from 10.0.0.139: icmp_seq=0 ttl=128 time=0.391 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=1 ttl=128 time=0.380 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=2 ttl=128 time=0.500 ms
wrong total length 84 instead of 124
64 bytes from 10.0.0.139: icmp_seq=3 ttl=128 time=0.369 ms
wrong total length 84 instead of 124
--- 10.0.0.139 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.369/0.410/0.500/0.052 ms
::*> network ping -destination 10.0.0.139 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87 -s true -R true -count 4 -v true
PING 10.0.0.139 (10.0.0.139) from 10.0.8.166: 56 data bytes
to 10.0.8.166 64 bytes from 10.0.0.139: icmp_seq=0 ttl=128 time=0.392 ms
wrong total length 84 instead of 124
to 10.0.8.166 64 bytes from 10.0.0.139: icmp_seq=1 ttl=128 time=0.374 ms
wrong total length 84 instead of 124
to 10.0.8.166 64 bytes from 10.0.0.139: icmp_seq=2 ttl=128 time=0.463 ms
wrong total length 84 instead of 124
to 10.0.8.166 64 bytes from 10.0.0.139: icmp_seq=3 ttl=128 time=0.443 ms
wrong total length 84 instead of 124
--- 10.0.0.139 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.374/0.418/0.463/0.037 ms
10.0.8.166
と意図したIPアドレスから実行されていることが分かりますね。
traceroute
ノードを指定する場合
続いてnetwork traceroute
です。
オプションを確認しておきます。
::*> network traceroute ?
{ -node <nodename> Node
| -lif <lif-name> } Logical Interface
-vserver <vserver> LIF Owner
[-destination] <Remote InetAddress> Destination
[[-maxttl|-m] <integer>] Maximum Number of Hops
[ -numeric|-n [true] ] Print Hop Numerically
[ -port <integer> ] Base UDP Port Number
[ -packet-size <integer> ] Packet Size
[ -nqueries|-q <integer> ] Number of Queries
[ -verbose|-v [true] ] Verbose Output
[ -waittime|-w <integer> ] Wait Between Packets (secs)
デフォルトではUDP/33434宛てに行うようです。
[-port <integer>] - Base UDP Port Number
Use this parameter to specify the base UDP port number used in probes. The default > is port 33434.
叩いてみましょう。
::*> network traceroute -destination 10.0.8.166 -node FsxId0e64a4f5386f74c87-01
traceroute to 10.0.8.166 (10.0.8.166), 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 0.059 ms 0.042 ms 0.036 ms
::*> network traceroute -destination 10.0.8.166 -node FsxId0e64a4f5386f74c87-02
traceroute to 10.0.8.166 (10.0.8.166), 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 2.024 ms 0.279 ms 0.252 ms
問題なく疎通できました。
詳細情報を出力するようにオプションを指定して再度実行します。
::*> network traceroute -destination 10.0.8.166 -node FsxId0e64a4f5386f74c87-01 -v true
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.229, 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 56 bytes to 10.0.8.229 0.060 ms 0.048 ms 0.039 ms
10.0.8.229
ということはinter_1
というLIFであることが分かります。
LIFを指定する場合
::*> network traceroute -destination 10.0.8.166 -lif ?
iscsi_1 ambiguous command
iscsi_2 ambiguous command
nfs_smb_management_1 ambiguous command
FsxId0e64a4f5386f74c87-01_clus_1 198.19.2.237
FsxId0e64a4f5386f74c87-02_clus_2 198.19.2.65
FsxId0e64a4f5386f74c87-01_mgmt1 198.19.3.141
FsxId0e64a4f5386f74c87-02_mgmt1 198.19.3.67
fsxadmin 10.0.8.166
inter_1 10.0.8.229
inter_2 10.0.8.62
::*> network traceroute -destination 10.0.8.166 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.166, 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 0.065 ms 0.042 ms 0.104 ms
::*> network traceroute -destination 10.0.8.166 -lif nfs_smb_management_1 -vserver svm
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.246, 64 hops max, 40 byte packets
1 ip-10-0-8-166.ec2.internal (10.0.8.166) 0.086 ms 0.053 ms 0.054 ms
::*> network traceroute -destination 10.0.8.166 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87 -v
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.166, 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 56 bytes to 10.0.8.166 0.058 ms 0.043 ms 0.040 ms
::*> network traceroute -destination 10.0.8.166 -lif nfs_smb_management_1 -vserver svm -v
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.246, 64 hops max, 40 byte packets
1 ip-10-0-8-166.ec2.internal (10.0.8.166) 56 bytes to 10.0.8.246 0.084 ms 0.062 ms 0.049 ms
ポート指定をしても動作することを確認します。
::*> network traceroute -destination 10.0.8.166 -lif fsxadmin -vserver FsxId0e64a4f5386f74c87 -v true -port 53
traceroute to 10.0.8.166 (10.0.8.166) from 10.0.8.166, 64 hops max, 40 byte packets
1 10.0.8.166 (10.0.8.166) 56 bytes to 10.0.8.166 0.067 ms 0.046 ms 0.037 ms
動作しますね。
tcpdump
pingやtracerouteを叩いても疎通確認ができない場合に途中のネットワーク機器やサービスのログを確認します。
それでも原因が特定できない場合はtcpdumpでパケットキャプチャをして、パケットのフローを確認します。
FSxNでもtcpdumpの実行が可能です。
network tcpdump start
: パケットキャプチャの開始network tcpdump show
: 実行中のパケットキャプチャの表示network tcpdump stop
: パケットキャプチャの停止
詳細は以下AWS公式ドキュメントで記載されています。
実際に試してみます。
::*> network tcpdump ?
Error: "tcpdump" is not a recognized command
はい、network
のサブコマンドにはありません。
以下Network KBにあるように、debug tcpdump
コマンドを叩く必要があるようです。
debug tcpdump ONTAP 9.10で使用できるコマンドの構文とオプション
複数の フィルタ、明示パス、またはその他のより複雑な機能が必要な場合を除き、以下を使用してください。 ONTAP 9.10以降のシステムでパケットトレースをキャプチャする方法
確認してみましょう。
::*> debug network ?
tcpdump> *Run tcpdump operations
::*> debug network tcpdump ?
show *Show running tcpdump instances
start *start tcpdump
stop *Stop an active tcpdump trace
::*> debug network tcpdump start ?
[-node] <nodename> *Node
[-ipspace] <IPspace> *IPspace
[-pass-through] <text> *Arguments (required: -i -w)
確かに先頭にdebug
を付与することでtcpdumpを実行できそうです。
tcpdump実行前に実行結果のファイルの出力先として指定するパスを確認します。
::*> volume show -fields junction-path -vserver svm
vserver volume junction-path
------- -------------------------- -------------
svm non_97_dev_fsvol_vol_test1 -
svm non_97_dev_fsvol_vol_test2 /vol_test2
svm svm_root /
svm vol1 /vol1
svm vol_ntfs /vol_ntfs
svm vol_ntfs_dst /vol_ntfs_dst
6 entries were displayed.
::*> cifs share show -vserver svm -path /vol_ntfs_dst
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm share-test /vol_ntfs_dst oplocks - Everyone / Full Control
browsable
changenotify
show-previous-versions
svm vol_ntfs_dst /vol_ntfs_dst oplocks - Everyone / Full Control
browsable
changenotify
show-previous-versions
2 entries were displayed.
svm
の/vol_ntfs_dst
に出力すれば、share-test
もしくはvol_ntfs_dst
でアクセスできそうです。
では、tcpdumpを実行します。
::*> debug network tcpdump start -node FsxId0e64a4f5386f74c87-01 -ipspace Default -pass-through "-i e0e -w /clus/svm/vol_ntfs_dst"
Info: Started network trace on interface "e0e"
::*> debug network tcpdump show
Node IPspace Port Filename
--------------- -------- -------- --------
FsxId0e64a4f5386f74c87-01
Default e0e /clus/svm/vol_ntfs_dst/FsxId0e64a4f5386f74c87-01_e0e_20241231_085734.trc
::*> debug network tcpdump show -instance
Node: FsxId0e64a4f5386f74c87-01
IPspace name: Default
Port: e0e
File Name: /clus/svm/vol_ntfs_dst/FsxId0e64a4f5386f74c87-01_e0e_20241231_085734.trc
Options: This field is not available on this platform.
実行が開始されました。
-pass-through
で指定できる値は以下のとおりです。
-B, --buffer-size=<KiB>
-c <number_of_packets>
-C <file_size-mB>
-F <filter_expression_filename>
-G <rotate_seconds>
--time-stamp-precision {micro|nano}
-Q, --direction {in|out|inout}
-s, --snapshot-length=<bytes>
-U, --packet-buffered
-W <rotate_file_count>
<filter-expression>
ファイル名やローテーションに関する設定が多いですね。
pcapのフィルターも設定可能です。ピンポイントでプロトコルやIPアドレスを絞り込みたい場合は指定してあげると出力ファイルのサイズを抑えることができます。
実行開始後、SMBファイル共有を覗くとFsxId0e64a4f5386f74c87-01_e0e_20241231_085734.trc
とtcpdumpの出力ファイルを確認できました。
tcpdumpを停止します。
::*> debug network tcpdump stop -node FsxId0e64a4f5386f74c87-01
Error: Either specify all keys, or set at least one key to "*".
::*> debug network tcpdump stop -node FsxId0e64a4f5386f74c87-01 -ipspace Default -port e0e
Info: Stopped network trace on interface "e0e"
停止後、trcファイルをWiresharkで開きます。
問題なく表示できますね。接続中のSSHセッションのパケットが確認できます。
また、SMBファイル共有にアクセスした際のパケットも確認できました。
トラブルシューティングのお供に
Amazon FSx for NetApp ONTAPファイルシステムやSVMからpingとtracerouteを実行してみました。
トラブルシューティングの時に非常に役立ちそうですね。
特にマネージドサービスでありながらtcpdumpを実行できるのは非常にありがたいです。
その他のマネージドサービスであれば、VPC Traffic Mirroringを用いてそのマネージドサービスのENIに対してtcpdumpを行うことになります。
こちらと比較すると、非常にお手軽です。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!